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Abstract 

Type classes provide a mechanism for varied implementations of 
standard interfaces. Many of these interfaces are founded in mathe- 
matical tradition and so have regularity not only of types but also of 
properties (laws) that must hold. Types and properties give strong 
guidance to the library implementor, while leaving freedom as well. 
Some of this remaining freedom is in how the implementation 
works, and some is in what it accomplishes. 

To give additional guidance to the what, without impinging on 
the how, this paper proposes a principle of type class morphisms 
(TCMs), which further refines the compositional style of denota- 
tional semantics. The TCM idea is simply that the instance's mean- 
ing follows the meaning's instance. This principle determines the 
meaning of each type class instance, and hence defines correctness 
of implementation. It also serves to transfer laws about a type's se- 
mantic model, such as the class laws, to hold for the type itself. In 
some cases, it provides a systematic guide to implementation, and 
in some cases, valuable design feedback. 

The paper is illustrated with several examples of types, mean- 
ings, and morphisms. 

1. Introduction 

Data types play a central role in structuring our programs, whether 
checked statically or dynamically. Data type representations col- 
lect related pieces of information making its use more convenient. 
Adding data abstraction gives a clean separation between a type's 
interface and its implementation. The ideal abstraction is as simple 
as possible, revealing everything the users need, while shielding 
them from implementation complexity. This shield benefits the im- 
plementor as well, who is free to improve hidden implementation 
details later, without breaking existing uses. 

What kind of a thing is an interface that can connect implemen- 
tors with users while still serving the distinct needs of each? 

Part of the answer, which might be named the "form", is a 
collection of names of data types and names and types of operations 
that work on them. For instance, for a finite map, the interface may 
include operations for creation, insertion, and query: 

abstract type Map :: * — > * — > * 
empty :: (...) => Map k v 

insert :: (...) => k — > v — > Map k v — > Map k v 
lookup :: (Eq k...) => Map k v — > k — > Maybe v 

The type signatures will eventually include additional limitations 
(constraints) on the type parameters. The representation of Map 
and the implementation of its operations are not revealed. 

By itself, the form of the interface does not deliver the promised 
shield. Although it successfully hides implementation details, it 
fails to reveal an adequate replacement. While the implementation 
reveals too much information to users, the signatures provide too 



little. It is form without essence. Users of this abstraction care about 
what functionality these names have. They care what the names 
mean. 

Which leads to the question: what do we mean by "mean"? 
What is the essence of a type, enlivening its form? One useful an- 
swer is given by denotational semantics. The meaning of a program 
data type is a type of mathematical object (e.g., numbers, sets, func- 
tions, tuples). The meaning of each operation is defined as a func- 
tion from the meanings of its arguments to the meaning of its result. 
For instance, the meaning the type Map k v could be partial func- 
tions from k to v. In this model, empty is the completely undefined 
function, insert extends a partial function, and lookup is just func- 
tion application, yielding _L where undefined. The meaning of the 
type and of its operations can be spelled out precisely and simply, 
as we will see throughout this paper. 

Haskell provides a way to organize interfaces via type classes 
(Wadler and Blott 1989; Jones 1993). Library designers can present 
parts of a type's interface as instances of standard type classes, 
which then provides the library's users with standard vocabularies, 
thus making the library more easily learned. In addition to reducing 
learning effort, type class instances make libraries more useful, 
thanks to other libraries that contain functionality that works across 
all instances of given type classes. 

Type classes provide more than names and types of operations. 
They also specify laws to be satisfied by any instance. For example, 
a Monoid instance must not only define a 0 value and a binary 
(©) operation of suitable types (called "mempty" and "mappend" 
in Haskell). Also, 0 must be a left and right identity for (©), and 
(ffi) must be associative. Thus a type class determines part of the 
essence, as well as the form, of each of its instances. 

What about the rest of the meaning of a type class instance-the 
semantic freedom remaining after the types and laws have had their 
say? This paper suggests a principle for answering that question: 

The instance's meaning follows the meaning's instance. 

That is, the meaning of each method application is given by ap- 
plication of the same method to the meanings of the arguments. In 
more technical terms, the semantic function is to be a type class 
morphism, i.e., it preserves class structure. 

For example, suppose we want to define a Monoid instance for 
our finite map type. The type class morphism (TCM) principle tells 
us that the meaning of 0 on maps must be 0 for partial functions, 
and the meaning of (©) of two maps is the (©) of the partial 
functions denoted by those maps. 

This paper provides several examples of types and their mean- 
ings. Sometimes the TCM property fails, and when it does, exami- 
nation of the failure leads to a simpler and more compelling design 
for which the principle holds. In each case, class laws are guaran- 
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teed to hold, thanks to the morphisms, and so need not be proved 
specifically. The laws thus come, if not "for free", then "already 
paid for". Often, for a simple and fitting semantic model, some- 
one already has done the hard work of verifying class laws, so the 
library designer can smile and accept the gift. When the model is 
unusual or complex enough that the work has not been done, it may 
be that either the model can be improved, or someone can do the 
hard work for the model and share it with others. If it is true, as I 
believe, that good semantic models tend to be reusable, then there 
is leverage to be gained from TCMs. 

Adopting the discipline illustrated in this paper requires addi- 
tional up-front effort in clarity of thinking, just as static typing does. 
The reward is that the resulting designs are simple and general, and 
sometimes have the feel of profound inevitability — as something 
beautiful we have discovered, rather than something functional we 
have crafted. A gift from the gods. 

2. Denotational semantics and data types 

Denotational semantics is a compositional style for precisely speci- 
fying the meanings of languages, invented by Christopher Strachey 
and Dana Scott in the 1960s (Scott and Strachey 1971; Stoy 1977). 
The idea is to specify, for each syntactic category C, 

• a mathematical model [C] of meanings, and 

• a semantic function [-] c :: C — > [C]. 

Moreover, the various [-] c must be compositional, i.e.,must be 
defined by (mutual) structural recursion. Notationally, "|-] c c" 
is shortened to "|c] c ", and when unambiguous, will be 

shortened to "[•]". 

Similarly, we can apply denotational semantics to data types 
within a language to give precise meaning, independent of its 
implementation. Doing so yields insight into the essence of a type, 
which may lead to its improvement, or to informed choices about its 
use. It also supports clear reasoning while implementing or using 
the type. 

As an example, consider a data type of finite maps from keys 
to values. The type is abstract, available only through an explicit 
interface that does not reveal its representation. A central question 
is "What does a map mean!" In other words, "A map is a repre- 
sentation of what mathematical object?" A simple first answer is 
a partial function from values to keys. Next, we'll want to be clear 
about the sense of "partial" here. When a map is queried for a miss- 
ing key, we might want the map to yield an error (semantically _L). 
More likely, we'll want an indication that allows for graceful re- 
covery. For this reason, it's appealing to model a map's partiality 
via a success/failure type, for which Haskell's Maybe type is well 
suited. Thus a workable model for maps is 

[Map k vj = k — > Maybe v 

For a language, the meaning function is defined recursively over 
the abstract syntactic constructors. This practice transfers directly 
to algebraic data types. We are doing something different, however, 
which is to define the meaning of an interface, without any refer- 
ence to representation. 

Return now to the interface from Section 1: 

abstract type Map :: * — > * — > * 
empty :: (...) => Map k v 

insert :: (...) => k — > v — > Map k v — > Map k v 
lookup :: (Eq k...) => Map k v — > k — > Maybe v 

The omitted additional type constraints contribute only to the im- 
plementation and not the semantics. (With Ord k for insert and 
lookup, the implementation can use a balanced tree representation 
(Adams 1993).) 



A semantics for Map then consists of a model, as given above, 
and an interpretation for each member of the interface. 

[■] :: Map k v — > (k — > Maybe v) 
\empty\ = \k — » Nothing 

\insert k' v m] = \k — > if k = k' then Just v else [m] k 
{lookup m kj = [m] k 

Many more functions on maps can be defined semantically within 
this model, such as a left-biased "union": 

unionL :: (...) => Map k v — > Map k v Map k v 
{ma 'unionL 1 nib] = \k — > [mo] k 'mbLeft 1 [mb] k 

mbLeft :: Maybe v Maybe v — > Maybe v 
mbLeft (Just v) _ = Just v 
mbLeft Nothing mb' = mb' 

Other functions can be defined in terms of simpler functions. 
For instance, a map defined for only a single key is semantically 
equivalent to one made via empty and insert. 

singleton :: (...) => k — > v — > Map k v 
singleton k v = insert k v empty 

Given this relationship, an explicit semantics for singleton would 
be redundant. 

What is the meaning of equality (i.e., (=)) here? The answer 
used throughout this paper is that equality is semantic, i.e., 

a = b [a] = [bj 

We can use lookup to find out whether a key has a correspond- 
ing value, i.e., whether the key is in the map's domain. Suppose we 
want to know what the domain is without having to query? Maybe 
we want to know the size of the map's domain (number of defined 
keys). 

size :: Map k v — > Integer 

{size to] = \{k | [m] k ^ Nothing}\ 

This semantics does not give much hint of how to implement size. 

3. Simplicity 

Most of the time, we programmers reason casually and informally 
about our programs, and such reasoning is useful. Sometimes we 
want to make sure that our casual reasoning is valid, so precision 
tools are useful. For instance, an important aspect of software 
design is simplicity of use. Specifying semantics precisely gives 
us a precise way to measure and compare simplicity of designs. 1 
Moreover, and of great practical importance, simpler designs are 
easier to reason about, giving us the opportunity to reason further 
and more deeply. Benefits to software include wider applicability, 
easier use, and better implementation performance. 

The model we used for maps is fairly simple, k — > Maybe v. 
Can we simplify it further? It only has two parts, (— ») and Maybe. 
The function part is essential to what a map is, while the Maybe 
part is an encoding of partiality. 



1 In my experience, simplicity often brings generality along with it. When 
I design an interface, I usually have in mind some things I want to do 
with it and how I want it to behave for those things. A complex design 
is able to address each of those uses and desired behaviors specifically. 
A simple design, however, requires achieving these specific goals without 
correspondingly specific design features. Instead, the design must make 
do with less specifics, by exploiting more general principles. As a result, 
unforeseen uses are more likely to be covered as well. 
"Perfection is achieved not when there is nothing left to add, but when there 
is nothing left to take away" (Antoine de Saint-Exupery). In mystical terms, 
simplicity tugs the human designer out of the way and into the flow of the 
master Designer (Mathematics, God, The Tao, the elegant universe, etc). 
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One way to simplify our model is to keep just the function part, 
and factor out the Maybe. Think of k — > Maybe v not as a partial 
map from k to v, but as a total map from k to Maybe v. Then 
simplify and generalize to total maps to arbitrary types. 2 

abstract type TMap k v - total map 

[TMap kv} = k^v 

The interface for Map doesn't quite fit TMap, so let's make 
some changes: 



constant 

update 

sample 



(...) => v — » TMap A; v 
(...) => fc — > v — > TMap fc v 
(Eg A;...) TMap fc v -> fc -> 'u 



TMap A; u 



• In place of an empty Map, we can have a constant TMap. 

• Instead of inserting a key/value pair (possibly overwriting), 
we'll update a key (definitely overwriting). 

• Sampling a map to a key always has a defined value. 

As one might guess, simplifying the semantic model also sim- 
plifies the semantic function: 

[■] :: TMap k v -> (k -> v) 
\constant v\ — \k —> v 

{update k' v m] = \k — > if k = k' then v else [m] k 

\sample m k\ — [m] k 

We can mimic partial maps in terms of total maps: 

type Map k v = TMap k (Maybe v) 

empty = constant Nothing 

insert k' v m = update k' (Just v) m 
lookup m k = sample m k 

What can a union l of total maps mean? For Map, union l had 
to handle the possibility that both maps assign a value to the same 
key. With TMap, there will always be conflicting bindings. The 
conflict resolution strategy for Map is specific to Maybe. We can 
simplify the design by passing a combining function: 

unionWith :: (...) => (a — > b — > c) 

-> TMap k a -> TMap fc 6 -> TMap A; c 

{unionWith f ma mbj = \k —> f ([ma] A;) ([mb] A;) 

This unionWith function is simpler (semantically) than union l 
on Map. As the type shows, it is also more general, allowing maps 
of different value types. 

Some of our gained simplicity is illusory, since now the client 
of unionWith must provide a definition of /. However, we can 
provide functionality that is as easy to use, using our definition of 
Map k v as TMap k (Maybe v). 

unionL :: (...) Map k v — ► Map k v — > Map k v 
union l = unionWith mbLeft 

This definition of union l is semantically equivalent to the one in 
Section 2. 

4. Type classes 

Type classes provide a handy way to package up parts of an inter- 
face via a standard vocabulary. Typically, a type class also has an 
an associated collection of rules that must be satisfied by instances 
of the class. 

For instance, Map can be made an instance of the Monoid 
class, which is 

2 For simplicity of presentation, this paper does not use the more strictly 
compositional form: {TMap k v\ = \k\ — > {vj. 



class Monoid o where 
0 :: o 

(ffi) :: o -> o -> o 

Haskell's mempty and mappend are 0 and (ffi), respectively. The 
required laws are identity and associativity: 



affil 



a 



0 ffi o =b 

a ffi (6 0 c) = (a 0 6) 0 c 

Is our type Map a 6 of partial maps a monoid? To answer 
"yes", we'll have to find definitions for 0 and (©) that satisfy the 
required types and properties. The types suggest a likely guess: 

instance Monoid (Map k v) where 
0 = empty 
(©) = union l 

It's straightforward to show that Map satisfies the monoid laws. 
The crucial lemmas are that Nothing is a left and right identity for 
mbLeft and mbLeft is associative. 

[ma © 0] 
ee { (©) on Map } 

\ma ' unionL 1 empty] 
ee { definition of union l } 

{unionWith mbLeft ma empty] 
ee { semantics of unionWith } 

AA; — * [ma] k L mbLeft i \empty\ k 
ee { semantics of 0 } 

AA; — ► [ma] k 'mbLeft 1 Nothing 
ee { lemma } 

AA; — ► [ma] k 
ee { r\ reduction } 

[ma] 

The other proofs are similar. 

What about TMapl Since total maps assign a value for every 
key, 0 will have to come up with a value from no information. 
Similarly, (ffi) will have to combine the two values it finds, without 
being given a specific combination function. Where do we get the 
empty value and the combining function? From another monoid. 

instance Monoid v => Monoid (TMap k v) where 
0 = constant 0 
(©) = unionWith (©) 

This instance satisfies the monoid laws, which is easier to show 
than for Map. The simplified reasoning testifies to the value of the 
simpler semantic model. 

However, there is a subtle problem with these two Monoid 
instances. Can you spot it? (Warning: Spoiler ahead.) 

Section 3 defined Map in terms of TMap. Given that definition, 
the Monoid instance for TMap imposes a Monoid for the more 
specific Map type. Are these two instances for Map consistent? 

Look at the standard Monoid instance for Maybe values: 



instance Monoid o = 
0 = Nothing 
Just a © Nothing 
Nothing © Just b 
Just a ffi Just b 



Monoid (Maybe o) where 



= Just a 
= Just b 
= Just (a i 



b) 



Since constant Nothing = constant 0, the two definitions 
of 0 for Map agree. So far, so good. Next, recall the combining 
function used to define union l on partial maps: 
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mbLeft :: Maybe v — > Maybe v — > Maybe v 
mbLeft (Just v) _ = Just v 
mbLeft Nothing mb' = mb' 

This combining function gives union l its left bias. When we 
define Map k v — TMap k (Maybe v), two changes result: the 
left bias is lost, and a constraint is added that v must be a monoid. 
So, no, the imposed Monoid instance for Map is not consistent 
with its desired, original meaning. 

We could eliminate this inconsistency by defining Map from 
scratch rather than via TMap. This solution comes at the cost of 
added complexity, overall. Fortunately, there is another solution 
that improves rather than degrades simplicity: fix the semantic 
model for Map. 

The source of the inconsistency is that Maybe has a Monoid 
instance, but it's the wrong one. It's unbiased where we want left- 
biased. The type's representation suits our needs, but its associated 
instance does not. So, let's keep the representation while changing 
the type. 

The Monoid library (Gill et al. 2001) provides some types for 
this sort of situation, including two wrappers around Maybe: 

newtype First a — First (Maybe a) 

deriving (Eq, Ord, Read, Show, Functor, ...) 

newtype Last a = Last (Maybe a) 

deriving (Eq, Ord, Read, Show, Functor, ...) 

The sole purpose of these type wrappers is to replace Maybe' s un- 
biased Monoid instance with a left-biased (First) or right-biased 
(Last) instance. 

instance Monoid (First a) where 

0 = First Nothing 

l@(First (Just _)) ffi _ = Z 

First Nothing ffi r — r 
instance Monoid (Last a) where 

0 = Last Nothing 

_ffi r@(Last (Just _)) = r 

1 ffi Last Nothing = I 

This (©) for First is just like the function mbLeft used for 
defining unions and hence (ffi) for Map. We can solve our con- 
sistency problem by replacing Maybe with First in Map: 

type Map k v = TMap k (First v) 

With this change, the Monoid instance for Map can disappear 
completely. The desired behavior falls out of the Monoid instances 
for TMap and First. 

This definition also translates to a new semantic model for 
partial maps: 

{Map k v] = k — > First v 

This new version hints of the left-bias of (ffi). It also gives a single 
point of change if we decide we prefer a right-bias: replace First 
with Last. 

5. Type class morphisms 

Section 2 illustrated how denotational semantics gives precise 
meaning to data types, which serves as a basis for casual and pre- 
cise reasoning. Simplicity of semantic models (Section 3) improves 
generality and ease of reasoning. Section 4 then brought in type 
classes, which give a consistent way to structure interfaces. The se- 
mantic models of instances give a basis for proving the associated 
class properties. 



Now we're ready to get to the heart of this paper, which is a 
synergy of the two disciplines of denotational semantics and type 
classes. 

5.1 Monoid 

Consider again the Monoid instance for total maps: 

instance Monoid v => Monoid (TMap k v) where 
0 = constant 0 
(©) = unionWith (ffi) 

Now recast it into semantic terms, with a "semantic instance", 
specifying the meaning, rather than the implementation, of a type 
class instance: 

instance sem Monoid v =>■ Monoid (TMap k v) where 
[0] = {constant 0] 
[(ffi)] = {unionWith (ffi)] 

The meanings of constant and unionWith are given in Section 3: 

{constant v] = \k — > v 

{unionWith f ma mb] = \k — > / ([ma] k) ({mb] k) 

Substituting, we get 

instance sem Monoid v =>■ Monoid (TMap k v) where 
[0] = \k -> 0 

{ma ffi mb] = \k —> [ma] k ffi {mb] k 

The RHSs (right-hand sides) of these semantic definitions re- 
semble an instance in the Monoid library: 

instance Monoid b => Monoid (a — » 6) where 

0 = Aa^0 

f®g = \a^fa®ga 

This instance lets us simplify the TMap semantic monoid instance: 

instance sem Monoid v Monoid (TMap k v) where 

[0] = 0 

(ma ffi mb] = {ma] ffi {mb] 

This property of [•] has a special name in mathematics: [•] is a 
monoid homomorphism, or more tersely a "monoid morphism". 

Note what has happened here. The semantics of the Monoid 
part of the TMap interface is completely specified by saying that 
[•] is a morphism for that class. 

The methods (0 and (ffi)) on the LHSs refer to the type being 
specified (here TMap k v), while the same methods on the RHSs 
refer to that type's meaning (here k — > v). The meaning of each 
method application is given by application of the same method 
on the meanings of the arguments. In other words, the semantic 
function is a morphism with respect to the class, i.e., preserves the 
structure defined by the class. 

Besides succinctness, why else might we care that a meaning 
function is a monoid morphism? Because this property means that, 
at least for the Monoid part of the interface, the type behaves like 
its model. As users, we can therefore think of the type as being its 
model. Functions are well-studied, so the experience we have with 
the model is a great help in thinking about the type. Our reasoning is 
shielded from the implementation complexity. The flip side is that 
we are cut off from reasoning about its operational performance. 

What about other type classes, besides Monoid! 

5.2 Functor 

The Functor interface is 

class Functor f where 

fmap :: (a -> 6) -> / a -> / b 

with laws: 
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fmap id 
fmap (h o g) 



: id 

; fmap h o fmap g 



A total map can be made an instance of Functor. Mapping a 
function over a total map applies the function to each value in a 
key/value binding: 

instance sem Functor (TMap k) where 
{fmap /m] = Afc-/([m] k) 

This semantic definition for fmap satisfies the compositional disci- 
pline of denotational semantics, in that the meaning of fmap f mis 
defined in terms of the meaning of its TMap argument, to. More- 
over, this semantics also satisfies the Functor laws: 

Ifmap id mj 
= { semantics of fmap } 

Xk -> id (\mj k) 
= { definition of id } 

\k -> [to] k 
= { r\ contraction } 

Imj 

{fmap (h o g) m] 
= { semantics of fmap } 

Xk^(hog) ([to] fc) 
= { definition of (o) } 

\k -> h (g (Imj k)) 
= { semantics of fmap } 

\k — > h Ifmap g m] k 
= { semantics of fmap } 

Xk — > {fmap h (fmap g m)J k 
= { n contraction } 

Ifmap h (fmap g to)] 

Now let's play with this definition. Write the RHS in point-free 
form, using function composition: 

{fmap f m] = / o [m] 
Next, note the Functor instance for functions: 

instance Functor ((—»•) a) where fmap — (o) 
Our fmap semantics then become 

Ifmap f m] = fmap f [m] 

This property of [■], often written as [•] o fmap f = fmap f o [•], 
also has special name in mathematics: [■] is a natural transforma- 
tion, also called a "morphism on functors" (Mac Lane 1998) or (for 
consistency) a "functor morphism". 

5.3 What is a type class morphism? 

The monoid and functor morphism properties say that the method 
structure is preserved. That is, the interpretation of a method appli- 
cation on a type T is the same method applied to the interpretations 
of the type- T arguments. 

As a design guide, I recommend that any semantic function for 
a type T (a) be as simple as possible without loss of precision, and 
(b) be a type class morphism (TCM) with respect to each of the type 
classes it implements. Consequently, users can think of the type as 
being its (simple) model, rather than being an implementation of 
the model. 

Another way to describe the TCM property is: 



\fmap / m] = fmap f [to] 

[mo 0 mb] = [mo] 0 [mb\ 

In the RHSs, [•] is recursively applied to each TMap argument, 
within exactly the same structure as appears in the LHSs. 

5.4 Applicative functor 

Let's try one more. The Applicative (applicative functor) type 
class has more structure than Functor, but less than Monad. The 
interface: 

inflxl 4 © 

class Functor f => Applicative f where 
pure : : a — » / a 

(©) ::/ (a- 6)-/ a-/ b 

As usual, this class also comes with collection of laws (McBride 
and Paterson 2008). 

This time, instead of thinking about what Applicative instance 
we might want for TMap, let's see if the TCM property will tell 
us. Suppose that TMap is an applicative morphism, i.e., 

instance sem Applicative (TMap k) where 
\pure bj = pure b 
[to/ © mxj = [m/] © [mi] 

Indeed, there is an Applicative instance for functions, where 
pure and (©) are the classic K and S combinators: 

instance Applicative ((—>) a) where 
pure b = \a — > b 
h® g = Ao — > (h a) (g a) 

Substituting the semantic instance (Applicative on functions) 
in the RHS of our Applicative instance for TMap above yields 

instance sem Applicative (TMap k) where 
{pure vj = Xk — > v 
\mf © mxj = Xk^ ([m/] k) ([mi] k) 

In other words, a pure map is one that maps all keys to the same 
value; and "application" of a map full of functions to a map full of 
arguments is defined pointwise. 

Often (©) is used via n-ary lifting functions: 

UftA 2 :: Applicative f => (a — > b — > c) 

-/ a-/ 6-/ c 
UftA 3 :: Applicative f^(a^b^c^d) 
' ^/ a^fb^f c^f d 



UftA 2 h u v = pure h © u © v 
UftA 3 h u v w = pure h © u © v © w 



The instance's meaning follows the meaning's instance. 

In other words, meaning preserves class structure, by preserving 
the structure of each method application, in ways suited to the type 
of each method. For instance, as shown above for TMap k v, 



For functions, simplifying the RHS of UftA 2 gives 

UftA 2 h u v = Xx — » h (u x) (v x) 

and similarly for liftA 3 . 

With these definitions in mind, let's look again at two of our 
functions on total maps, from Section 3 

constant :: (...) => v — > TMap k v 

unionWith :: (...) => (a — > b — > c) 

-> TMap k o -> TMap k b ~* TMap k c 

{constant vj = Xk — > v 

\unionWith f ma mb] = Xk —> f ([mo] k) ([mb] k) 
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Now we see that constant and unionWith are just synonyms for 
pure and liftA 2 , so we can eliminate the former terms (and their 
definitions) in favor of the Applicative ones. This change gives us 
more for less: our type's specification is simpler; and it can be used 
with libraries that work with applicative functors. 

We have a last question to answer: Does our Applicative in- 
stance satisfy the required laws? 

6. Class laws 

Section 5 showed that TMap satisfies the Monoid and Functor 
laws. Does TMap also satisfy the Applicative laws? We'll now 
see that the answer is "yes", simply because TMap is (by con- 
struction) an applicative morphism. 

Consider, for instance, the composition law. 

pure (o) © u © v © w = u © (v © w) 

We are defining equality semantically, i.e., u = v -<=> \u\ = \v\, 
so the composition law is equivalent to 

{pure (o) © u © v © uij = [it © (v © w)j 

Working left to right, 

\pure (o) © u © v © w\ 
= { [•] is an applicative morphism } 

{pure (o)] © [«] © [i>] © [w] 
= { [■] is an applicative morphism } 

pure (o) © [«] © [t;] © 
= { composition law on semantics } 

M ® (H ® H) 

= { [•] is an applicative morphism } 

[«] ®[v®w] 
= { [•] is an applicative morphism } 

[«©(?;© w)] 

The proofs for the other laws follow in exactly the same way. 

These proofs make no use of the specifics of the Applicative 
instance for TMap. They are, therefore, applicable to every type 
for which equality is defined by an applicative morphism (e.g., [•]). 

Similar reasoning and conclusions hold for the Monoid, Functor, 
Monad, and Arrow classes. As in (Wadler 1990), [■] is a monad 
morphism iff 

[return aj = return a 

[u^kj = [u] :>=[•] o 

The monad laws: 



return a ;»= / = f a 
m >= return = m 
(m »=/) »= g = m 3 

Left identity: 

[return a ^= /] 
= { [•] is a monad morphism } 

[return a] 3= [•] o / 
= { [•] is a monad morphism } 

return a ;»= [•] o / 
= { left identity on semantics } 

1/ aj 
Right identity: 

[to 3= return] 
= { [•] is a monad morphism } 

[m] 3= [•] o return 
= { [•] is a monad morphism } 

[to] >■= return 



■■ (Ax -> / x 3) 



■ left identity 

■ right identity 

■ associativity 



= { right identity on semantics } 

[to] 

Associativity: 

I(m^/)^ S ] 
= { [•] is a monad morphism } 

[i»3=/l>=H'S 
= { [•] is a monad morphism } 

(H»[-]o/)»[.]o S 
= { associativity on semantics } 

[m] 3= (As - [/ x] ^= [•] o g) 
= { [•] is a monad morphism } 

[m] (Ax - [/ x ^= fl]) 
= { definition of (o) } 

[m] »[-]o(Ai^/i» 3) 
= { [•] is a monad morphism } 

[to Ax -» / x »= 3] 

The same reasoning applies to arrows (Hughes 2000) as well. 
One law has a form different from those we've looked at so far, 
which is the extensionality property: If h is onto, then 

arr h^> f = arr h^> g => / = g 

The proof: 

arr /i 3g> / = arr h ^> g 

{arr h 3> /] = [arr h^> gj 
=> { [•] is an arrow morphism } 

{arr hj ^ [/] = [arr hj ^ [ 5 ] 
=> { [•] is an arrow morphism } 

arr h^>ffj = arr [gj 
=> { extensionality on semantics, and h is onto } 

1/1 = bi 

=> { semantic equality } 

1 = 9 



7. Type composition 

Trying the TCM game with Map in place of TMap reveals a 
problem. The Monoid case comes out fine, but let's see what 
happens with Functor. First, we'll have to make Map abstract 
again (not a synonym) so that we can define a Functor instance. 

abstract type Map 

{Map k vj — k — > First v 

Mapping a function over partial map modifies the defined values: 

instance se m Functor (Map k) where 
Ifmap f m] = \k -> fmap f ([to] k) 

The RHS fmap uses the Functor for First (derived from Maybe). 
Now if we simplify and re-arrange as with TMap, we get 

instance sem Functor (Map k) where 
\fmap f to] = fmap (fmap f) [to] 

So [•] is not a Functor morphism. 

A similar difficulty arises with Applicative. The map pure v 
has value v for every key. For a function-valued map mf and an 
argument- valued map tox, the map mf © mx assigns a defined 
value of / x to a key k if / is the defined value of mf at k and 
x is the defined value of mx at k. If mf or mx is undefined at k 
then so is mf © mx. This meaning is formalized in the following 
Applicative instance, which uses the Applicative instance for 
First (derived from Maybe): 
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instance se m Applicative (Map k) where 
\pure v\ = \k — > pure v 
[to/ © mi] = \k — > [m/] © [mx] fc 

Using the Applicative instance for functions, this instance be- 
comes 

instance sem Applicative (Map k) where 
\pure v\ = pure (pure v) 
[to/ © mx] = UftA 2 (©) [m/] [tox] 

Thus [•] is also not an Applicative morphism. 

Again, these failures look like bad news. Must we abandon the 
TCM principle, or does the failure point us to a new, and possibly 
better, model for Map, as in Section 4? 

The rewritten semantic instances above do not make use of any 
properties of Map other than being a composition of two functors 
for the first instance and two applicative functors for the second. 
So let's generalize. As McBride and Paterson (2008) observed, 
Functor and Applicative are closed under composition: 

newtype (ho g) a = O (h (g a)) 

instance (Functor h, Functor g) 

=> Functor (hog) where 
fmap f (O hga) = O (fmap (fmap f) hga) 

instance (Applicative h, Applicative g) 
=> Applicative (h o g) where 
pure a — O (pure (pure a)) 

O hgf © O hgx = O (UftA 2 (©) hgf hgx) 

Define the meaning of a composition to be a composition: 

l(h°g)tj =([h\og)t -types 
1° h 9 a l hog = O \hga\ h - values 

If \-\ h is a Functor morphism, then \-\ ho is also a Functor 
morphism, and similarly for Applicative. To see why, first consider 

fmap: 

[fmap f (O hga)\ hog 
= { fmap on h o g } 

\0 (fmap (fmapf) hga)} hog 
= i U hog definition} 

0 If map (fmap f) hga\ h 
= { {-] h is a Functor morphism } 

0 (fmap (fmapf) {hga\ h ) 
= { fmap on [/i] o g } 

fmapf (O \hga\ h ) 
= iU hog definition} 

fmapf \0 hga\ hog 

Then pure: 

{pure aj hog 
= { pure on h o g } 

\0 (pure (pure a))\ 
= { U hog definition} 

O [pure (pure o)] h 
= { {-] h is an Applicative morphism } 

O (pure (pure a)) 
= { pure on [ft] o g } 

pure a 

Finally, (©): 

[O hgf © O hgxj hog 
= { (©) on h o g } 
[O (UftA 2 (©) hgf hgx)\ hog 



= { U hog definition} 

O {UftA 2 (©) hgf hgxj h 
= {Hi, is an Applicative morphism } 

0 (UftA 2 (©) {hgf\ h {hgx\ h ) 
= { (©) on [hjog} 

O {hgf\ h © O lhgx] h 
= {[-Log definition} 

10 hgf] hog © [O hgx} 



Now redefine Map: 

type Map k = TMap k o First 

More explicitly, 

{Map k v\ = {(TMap k o First) vj 
= k —+ First v 

These definitions say exactly what we mean, more directly than the 
previous definition. A (left-biased) partial map is a composition of 
two simpler ideas: total maps and First (left-biased Maybe). Given 
this new, more succinct definition, we can scrap the Functor and 
Applicative semantic instance definitions as redundant. 

It may look like we've just moved complexity around, rather 
than eliminating it. However, type composition is a very reusable 
notion, which is why it was already defined, along with supporting 
proofs that the Functor and Applicative laws hold. 

8. Deriving type class instances 

Implementations of type class instances can sometimes be derived 
mechanically from desired type class morphisms. Suppose we have 
[■] :: T — » T', where T 1 belongs to one or more classes and [■] 
is invertible. Then, combining [•] and [-] -1 gives instances that 
satisfy the morphism properties. 

For instance, consider the Monoid morphism properties: 

PI =9 

[u © vj = [u] e H 

Because [•] o = id, these properties are satisfied if 

[[0]]- 1 EE [0]- 1 

[[ue^lpEEjHeH]- 1 

Then, because o [•] ee id, these properties are equivalent to 
the following class definition: 

instance Monoid T where 

0 = [0]- 1 

By construction, [•] is a Monoid morphism. Similarly for the 
other type classes. Assuming the class laws hold for T', they hold 
as well for T, as shown in Section 6. 

If [•] and have implementations, then we can stop here. 
Otherwise, or if we want to optimize the implementation, we can 
do some more work, to rewrite the synthesized definitions. 

9. Memo tries 

As an example of synthesizing type class instances, let's consider 
a form of memoization, based on a variant of the total maps from 
Section 2, namely a complete memo trie. The central idea of the 
function memoizer is associating a type of trie to each domain type 
we want to memoize over. 
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Following the idea of generic tries (Hinze 2000) and its imple- 
mentation with associated types (Chakravarty et al. 2005), define a 
class of types with trie representations: 3 

class HasTrie a where 
data (-») a :: * — > * 

The type a -» b represents a trie that maps values of type a to 
values of type b. The trie representation depends only on a. 

The HasTrie class also contains converters between functions 
and tries: 

trie :: (a — > b) — > (a -» b) 
untrie :: (a -» b) — > (a — > b) 

The untrie and trie methods must be an embedding-projection 
pair: 

trie o untrie = id 
untrie o trie C id 

The reason for (C) is that keys get fully evaluated while building 
and searching the trie structure, even if they are not evaluated by 
the function being memoized. 

Given the HasTrie class, memoization is trivial to implement: 

memo :: HasTrie a => (a — > b) — > (a — > b) 
memo — untrie o trie 

The second inverse property implies that memo approximates the 
identity function (semantically). In practice, memo = hyperstrict, 
where 

hyperstrict :: Hyper a => (a — > i) — > (a — > 6) 
hyperstrict f a = hyperEval a l seq l f a 

Here I've assumed a hyperEval function to evaluate its argument 
fully. This function could either be built-in magic, or defined as a 
method from a type class, Hyper. 

Multi-argument curried functions can be memoized by repeated 
uses of memo. For instance, 

memo 2 :: (HasTrie a, HasTrie b) => 

(a — > b — > c) — > (a — > 6 — > c) 
memo2 f = memo (memo o /) 

9.1 A semantic false start 

Using [■] = untrie as the semantic function looks promising. 
However, untrie has no inverse, simply because it only produces 
hyper-strict functions. This lack of invertibility means that the 
synthesis technique in Section 8 fails to apply. 

Worse yet, untrie cannot be a monoid morphism for any 
Monoid instance of a -» b. To see why, assume the simplest 
morphism property, the Monoid identity: untrie 0 = 0. Applying 
trie to both sides, and using trie o untrie = id, it must be that 
0 = trie 0. It then follows that 

untrie 0 = untrie (trie 0) 
= hyperstrict 0 

We're okay if hyperstrict 0 = 0, but that is not the case, because 0 
on functions is Xx — > 0, which is not even strict (assuming 0 ^ _L). 

The conclusion that untrie cannot be a monoid morphism 
sounds like a failure, while in fact it gives us helpful informa- 
tion. It says that untrie cannot be our semantic function and why it 
cannot. The difficulty came from the presence of non-hyper-strict 
functions in the semantic domain, so let's remove them. Instead of 
modeling tries as functions, model them as hyper-strict functions, 
which we'll write as "a —> 6": 



Hyper-strict functions can be defined purely mathematically, for 
use in specifications only, or they can be defined in the implemen- 
tation language: 

newtype a^b = H { unH :: a — > b} 

With the condition that the contained a — > b is hyper-strict. 

With this new and improved semantic domain, we can define a 
semantic function: 

[•]::(a-» 6)-(a*6) 
[■] = H o untrie 

The reason we can legitimately use H here is that untrie always 
produces hyper-strict functions. 

9.2 Type class morphisms regained 

The problem with our first attempt (Section 9.1) was that the se- 
mantic function was not invertible. The new semantic function, 
however, is invertible. 

l-j- 1 ::(a^b)^(a^ b) 
[■] 1 = trie o unH 

That o [■] = id follows as before: 

iwr 1 

ee { and [-1 definitions } 

trie (unH (H (untrie t))) 
ee { unH o H ee id } 

trie (untrie t) 
ee { trie o untrie = id} 

t 

To show [•] o ee id, we'll have to exploit hyper-strictness: 

P/]" 1 ] 
== { [•] and definitions } 

H (untrie (trie (unH hf))) 
= { untrie o trie = hyperstrict } 

H (hyperstrict (unH hf)) 
= { unH hf is already hyper-strict } 

H (unH hf) 
= {Ho unH = id} 

hf 

Because (5-) is a newtype, H and unH are both strict, so this 
last step works even if hf = _L, The next-to-last step relies on _L 
being hyper-strict (trivially true, since _L maps everything to _L). 
Because [■] is invertible, we can synthesize instances for a -» b 

for all of the classes that the semantic model (a -5- 6) inhabits, as 
shown in Section 8. As desired, [•] is, by construction, a morphism 
with respect to each of those classes. 

9.3 Some trie representations 

Now let's consider choices for trie representations. As in (Hinze 

2000), the key is to exploit type isomorphisms. Letting a — > b be 
the set of (head-)strict functions from a to b, 



1 — > a 



This formulation is based on a design from Spencer Janssen. 



(a + b) - 
(a x b) ■ 



* c) X (b — > c) 
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instance HasTrie () where 
data () -» a = UnitTrie a 
trief = UnitTrie (/ ()) 
untrie ( UnitTrie a) = A() — ► a 

instance {HasTrie a, HasTrie b) => 

HasTrie (Either a b) where 
data (Either a b) -» x = EitherTrie (a -» x) (b -» x) 
trie f = EitherTrie (trie (f o Left)) (trie (/ o Right)) 
untrie (EitherTrie s t) = either (untrie s) (untrie t) 

instance (HasTrie a, HasTrie b) =>■ HasTrie (a, b) where 
data (a, b) -» x — PairTrie (a -» (b -» x)) 
trie f — PairTrie (trie (trie o curry /)) 
untrie (PairTrie t) = uncurry (untrie o untrie t) 



Figure 1. Some instances for memo tries 
which correspond to the familiar laws of exponents: 

1 

a = a 

a+6 ~, a . , b 
C = C X c 

axb / b\a 

c =(c) 

(These isomorphisms are slightly simpler than in (Hinze 2000), 
because they describe total rather than partial maps.) 

The intention is to apply these isomorphisms recursively, but 
head-strictness will only take us one level. To go all the way, we'll 
need hyper-strictness. 

1 — > a = a 
(a + b) -5- c = (a -5 c) x (b -3- c) 
(a x 6) -5- c = o -5-(i> -5- c) 
Writing these type isomorphisms in Haskell: 

()-*« -° 

Either a b -5- c = (a -5 c, 6 -5 c) 

(a,6)-5-c = a^*(b^c) 

which leads to the HasTrie instances defined in Figure 1. Since 
there is only one (non-bottom) value of type (), a trie over () con- 
tains just a single value, as suggested in the isomorphism equa- 
tion. A trie for sum-valued domains contains two tries, while a 
trie for pair-valued domains contains nested tries. Tries for other 
types, such as Bool, can be implemented via isomorphisms using 
the types above, or directly. For instance, Bool is isomorphic to to 
Either () (). 

Exercise: Prove that trie o untrie = id and untrie o trie = 
hyperstrict for the definitions above. 

9.4 Instances for hyper-strict functions 

If we want [•] to be a monoid morphism, then its range (the 
semantic domain) must be a monoid, and similarly for other type 
classes. 

Indeed, there are simple instances for hyper-strict functions: 

instance (Hyper a, Monoid b) => Monoid (a^> b) where 
0 = hyper 0 

H f®H g = hyper (f 0 g) 

where 

hyper = H o hyperstrict 



Similarly for Functor and Applicative. 

Using the Monoid instance for functions, we can get a more 
explicit definition of (©): 

hyper (f 0 g) 
= { (©) on functions } 

hyper (\a — > / a © g a) 
= { definitions of hyper and hyperstrict } 

H (\a — » hyperEval a 'seq' (/ a © g a)) 

Since / and g were inside an H, they are hyper-strict, so the 
additional hyper-evaluation of a is unlikely to be needed. Rather 
than carry it around, let's add an assumption, which is that (©) is 
strict in its first or second argument. Under this assumption, / © g 
is already hyper-strict. 
Starting again, 

H (hyperstrict (/ © g)) 
= { hyper-strictness of / © g } 
H{f®g) 

Now we can show that the monoid laws hold. Start with the 
right-identity law, hf © 0 = hf. There are two cases: hf = H f 
for some hyper-strict /, or hf = _L. First take the defined case: 

H /©0 

= { 0 for a ^ b } 

H f © hyper 0 
= { hyper definition } 

H f © H (hyperstrict 0) 

= { (ffi) on a -5 b } 

H (hyperstrict (f © hyperstrict 0)) 
= { assumption on (©) } 

H (hyperstrict (hyperstrict (f ffi 0))) 
= { monoid right-identity for functions } 

H (hyperstrict (hyperstrict /)) 
= { / is hyper-strict } 

H (hyperstrict f) 
= { f is hyper-strict } 

Hf 

The case of hf = _L is easier: 

-Lffi0 

= { pattern-match on _L } 
_L 

The other two monoid morphism laws follow similarly. 

10. Numeric overloadings 

Overloading makes it possible to use familiar and convenient nu- 
meric notation for working with a variety of types. The principle 
of type class morphisms can help to guide such overloadings, sug- 
gesting when to use it and how to use it correctly. 

10.1 Functions 

As an example, we can apply numeric notation for manipulating 
functions. Given functions / and g, what could be the meaning of 
/ + 9' f * 9' recip /, sqrt /, etc? A useful answer is that the 
operations are applied point-wise, i.e., 

f + g =\x^fx + gx 
f * g =\x^fx*gx 
recip f = \x — > recip (f x) 
sqrt f = \x — » sqrt (f x) 
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It's also handy to add literal numbers to the mix, e.g., 5 * sqrt f, 
which can mean Xx — > 5 * sqrt (f x). In Haskell, numeric literals 
are overloaded, using fromlnteger and fromRational, so add 

fromlnteger n = const (fromlnteger n) 

And similarly for rational literals. 

Thanks to the Functor and Applicative instances for functions 
(given in Section 5), these interpretations are equivalent to 

fromlnteger — pure o fromlnteger 
(+) = liftA 2 (+) 

(*) = liftA 2 (*) 

recip — fmap recip 

sqrt — fmap sqrt 



With this rephrasing, these definitions can be used not just with 
functions, but with any applicative functor. 

This notation is convenient and pretty, but what justifies it, se- 
mantically? Looking below the notation, in what sense can func- 
tions be interpreted as numbers? 

A compelling answer would be a simple function [■] mapping 
functions to a familiar number type, such that the [•] is a "nu- 
meric morphism", i.e., a morphism over all of the standard numeric 
classes. 

Is there such a [•]? Yes! And better yet, there's a great wealth of 
them. The functions / and g above have type a — * b for a numeric 
type b. Define a family of interpretation functions indexed over a. 
For all x :: a, 

[•]*:: (a - 6) - 6 
[/if = hx 

Then every J-] 1 is a numeric morphism. To see why, consider two 
operations. The others all work out similarly. 4 

{fromlnteger nj x = (fromlnteger n) x 

= (const (fromlnteger n)) x 
= fromlnteger n 



If + gV 



= (l + g) * 

= f x + g x 

= VV + bT 



There is another way to prove the numeric morphisms, which trans- 
fers to many similar situations. Show that the numeric morphism 
properties follow from the second style of definition above, in terms 
of fmap, pure, and UftA 2 , which is a very common pattern. To 
make the proof go through, change the model trivially, to be Id b 
instead of b, and make use of Id being a functor and applicative 
functor. 

[•]* :: (a^b)^Idb 

For now, assume that [•]* is a Functor and Applicative mor- 
phism, and that the numeric instances are defined in terms of fmap, 
pure, and Applicative as above. 

Ifromlnteger n\ x 
= { fromlnteger on type } 

4 There is a technical difficulty in a Haskell implementation. The Num class 
(and hence its descendants) are required also to implement Eq and Show. 
The methods of those classes cannot be defined such that {-} x is an Eq or 
Show morphism, because (=) yields Bool and show yields String, One 
could perhaps fix this problem by making these classes more morphism- 
friendly or by eliminating them as a superclass of Num. My thanks to 
Ganesh Sittampalam for pointing out this issue. 



\pure (fromlnteger n)\ x 
= { is an Applicative morphism } 

pure (fromlnteger n) 
= { fromlnteger on model } 

fromlnteger n 

If + gY 

= { (+) on type } 

\liftA 2 (+) f gj x 
= { is an Applicative morphism } 

UftA 2 (+) lfj x lg] x 
= { (+) on model } 

ur + br 

This proof makes no use of the specifics of the Functor and 
Applicative instances. 

Now show that {-] x is indeed a Functor and Applicative 
morphism: 

{fmap h f} x 
= { fmap on functions } 

[W]" 
ee { definition of |-f } 

Id (h (f x)) 
ee { fmap on Id } 

fmap h (Id (f x)) 
= { definition of jj-f } 

fmap h [/] 

{pure a] x 
ee { pure on functions } 

{const a\ x 
= { definition of |-f } 

Id (const a x) 
ee { definition of const } 

Id a 

ee { pure on Id } 
pure a 

{hf ® aff 
ee { (©) on functions } 

\\z - (hf z) (af z)f 
= { definition of [•]* } 

Id ((hf x) (af x)) 
= { (©) on Id } 

ID (hf x) ®ID(af x) 
= { definition of |-f } 

Wj ® bfj 

10.2 Errors 

For semantic simplicity, errors can be represented as _L. If we want 
to respond to errors in a semantically tractable way (hence without 
resorting to 10), we'll want an explicit encoding. One choice is 
Maybe a, where Nothing means failure and Just s means success 
with values s :: a. Another choice is Either x a, where Left err 
means a failure described by err ::x, while Right s means success. 

Programming with either explicit encoding can be quite tedious, 
but a few well-chosen type class instances can hide almost all of the 
routine plumbing of failure and success encodings. The key again 
is Functor and Applicative. The following instances suffice. 

instance Functor (Either x) where 
fmap _ (Left x) = Left x 
fmap f (Right y) = Right (f y) 
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instance Applicative (Either x) where 
pure y = Right y 
Left x © _ = Left x 

© Left x — Left x 
Right f © Right x — Right (/ x) 

A simple semantics for Either forgets the error information, 
replacing it with _L: 

[•] :: Either e a — > a 
{Left e\=± 
{Right aj — a 

To give Either e a numeric instances, follow the same tem- 
plate as with functions (Section 10.1), e.g., (+) = UftA 2 (+). The 
numeric morphism properties hold only if the numeric methods on 
the type a are strict. For an n-ary function h that is strict in all n 
arguments: 

lliftA n f e 1 ...e n j=f[e 1 j...[e n j 

where fmap = liftA 1 . The relevance of (_L-)strictness here is 
that (©) on Either yields a Left if either argument is a Left. For 
instance, consider fmap: 

{fmap f (Left x)j 
= { fmap for Either x } 

{Left xj 
ee { definition of [■] } 

_L 

ee { strictness of / } 
/-L 

ee { definition of [•] } 

/ [Left xj 

The other UftA n are proved similarly. Assuming (+) is strict then, 

le + e'j 
ee { (+) on Either x y } 

lliftA 2 (+) e e'l 
= { (+) is strict } 

[e] + [e'] 

The semantic property on liftA n above is nearly a morphism 
property, but the UftA n is missing on the right. We can restore it by 
changing the semantic domain: 

newtype Id a — Id a 

[•] :: Either e a — ► Id a 
[Left e] = Id _L 
[Right aj — Id a 

[•] is almost a Functor and Applicative morphism, but not quite, 
because of the possibility of non-strict functions. The proof at- 
tempts: 

[fmap f (Left x)] = [Left xj 

EE Id _L 

= Id(f±) -iff is strict 

ee fmap f (Id _L) 
ee fmap f [Left xj 



[fmap f (Right y)j 



[pure yj 



[Right (f y)j 
= U (f y) 
ee fmap f (Id y) 
ee fmap f [Right yj 

ee [Right yj 
= Idy 



[Left x®yj 



ee pure y 

ee [Left xj 
= Id± 
= Id±® [yj 
ee [Left xj © [yj 



[Right f © Left xj = [Left xj 
= Id± 

ee Id (/ _L) -iff is strict 

ee id / © Id _L 

ee [Right fj © [ie/t i] 



[Right f © ffipfa x] 



[Right (f x)j 

Id (f x) 

Id f © Id x 

[Right fj © {Right xj 



10.3 Expressions 

Another use of numeric overloading is for syntax manipulation, as 
in compiling domain-specific embedded languages (Elliott et al. 
2003; Augustsson et al. 2008). In this context, there is a parame- 
terized type of numeric expressions, often an algebraic data type. 
Using generalized algebraic data types (Peyton Jones et al. 2006) 
helps with static typing. 

10.3.1 Simple expressions 

A simple representation for expressions replaces each method with 
a constructor: 



data E :: * — > * 
Fromlnteger 
Add 
Mult 

FromRational 
Recip 



where 

: Num a - 
: Num a - 
: Num a - 



Integer 
E a ^ E a 
E a ^ E a 



E a 
E a 
E a 



: Fractional a 
: Fractional a 



Rational 
E a 



E a 
E a 



A convenient way to build up expressions is through numeric over- 
loading, e.g., 

instance Num a => Num (E a) where 

fromlnteger = Fromlnteger 
(+) = Add 

(*) = Mult 

instance Fractional a =>- Fractional (E a) where 
fromRational = FromRational 
recip = Recip 

Expressions are not just representations; they have meaning. To 
make that meaning precise, define a semantic function: 



[■jy.Ea^a 

[Fromlnteger nj 
[Add a bj 
[Mult a bj 



■■ fromlnteger n 

■ H + [bj 

■ 14 * [6] 



[FromRational nj = fromRational n 
[Recip aj = [recip aj 
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To ensure that expressions behave like what they mean, check 
that [•] is a morphism over Num and Fractional. The definitions 
of [•] and the instances make the proofs trivially easy. For instance, 



{Add a b] = [a] + \b} 



using the definitions of (+) on E and [•] on Add. 

How robust are these numeric morphisms? If the representation 
deviates from their one-to-one correspondence with methods, will 
the numeric morphism properties still hold? 

Let's try some variations, including self-optimizing expressions 
and expressions with variables. 

10.3.2 Generalizing literals 

As a first step, replace Fromlnteger and FromRational with a 
general constructor for literals. 

data E :: * — > * where 

Literal :: a — > E a 

Change the relevant methods: 

instance Num a => Num (E a) where 

fromlnteger = Literal o fromlnteger 

instance Fractional a Fractional (E a) where 
fromRational = Literal o fromRational 

Finally, replace two [•] cases with one: 
{Literal xj = x 

Everything type-checks; but does it morphism-checkl Verify the 
two affected methods: 

Ifromlnteger n] 
= {Literal (fromlnteger n)] 
= fromlnteger n 

and simiarly fox fromRational. Morphism check complete. 

10.3.3 Adding variables 

Our expressions so far denote numbers. Now let's add variables. We 
will use just integer- valued variables, to keep the example simple. 5 
The new constructor: 

Varlnt :: String — > E Int 

This small syntactic extension requires a significant semantic 
extension. An expression now denotes different values in different 
binding environments, so the semantic domain is a function: 

type Env = TMap String Int 
type Model a — Env —> a 
[■] :: E a -> Model a 

The semantic function carries along the environment and looks up 
variables as needed: 

look :: String — > Model Int 
look s e — sample e s 

{Literal xj _ = x 
{Varlnt v] e = look v e 

{Add a 6] e = [a] e + {b] e 
{Mult a 6] e = [a] e * [6] e 

5 Multi-type variable binding environments can be implemented with an 
existential data type and a GADT for type equality. 



{Recip a] e — recip [a] e 

Again, we must ask: is [■] a numeric morphism? In order for the 
question to even make sense, the semantic domain must inhabit the 
numeric classes. Indeed it does, as we saw in Section 10.1. 

Looking again at the numeric methods for functions, we can see 
a familiar pattern in the [•] definition just above. Using the function 
methods from Section 10.1, we get a more elegant definition of [•]: 

{Literal xj — pure x 
{Varlnt vj = look v 

{Add abj = {a} + {bj 
{Mult abj = [a] * [6] 
{Recip a] = {recip a] 

With this [•] definition, the morphism properties follow easily. 

10.3.4 Handling errors 

So far, expression evaluation is assumed to succeed. The variable 
environment yields values for every possible variable name, which 
is unrealistic. Let's now add error-handling to account for unbound 
variables and other potential problems. The result of a variable 
look-up or an expression evaluation will be either an error message 
or a regular value. 

type Result a — Either String a 

type Env — Map String Int 

type Model a — Env — > Result a 

look :: String — > Model Int 

look s e | Just n <— lookup e s = Right n 

| otherwise = Left ("unbound: " -ff s) 

[•] :: E a -> Model a 

Again, we'll rely on the Model having numeric instances, which 
is the case, thanks to the definitions in Sections 10.1 and 10.2. 

As with the semantic function in Section 10.3.3, the numeric 
methods for the semantic domain do almost all the work, leaving 
our semantic definition nearly intact. The only change is for literals: 

{Literal xj — pure (pure x) 

As before, most of the morphism proofs are trivial, due to the 
simplicity of the definitions. The fromlnteger and fromRational 
morphisms use Literal: 

{fromlnteger x} 
= { fromlnteger definition } 

{Literal (fromlnteger x)J 
= { [•] on Literal } 

pure (pure (fromlnteger x)) 
= { fromlnteger on Either a } 

pure (fromlnteger x) 
= { fromlnteger on a — > b } 

fromlnteger x 

and similarly fox fromRational. 

10.3.5 Self-optimizing expressions 

So far our expressions involve no optimization, but it's easy to 
add. For example, replace the simple method definition (+) = 
Add with the following version, which does constant-folding and 
recognizes the additive identity: 

Literal x + Literal y = Literal (x + y) 

Literal 0+6 = b 

a + Literal 0 = a 

a + b = Add a b 
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Other methods can perform similar optimizations. 

With this change, we must re-check whether [a + 6] = [a] + 
[6]. There are four cases to consider, corresponding to the four 
cases in the (+) definition. 

{Literal x + Literal yj 
= \Literal (x + y)J 
= x + y 

= {Literal x] + \Literal y\ 

[■J (Literal 0+6) 
= 0 + [6] 

ee {Literal 0] + [6] 

The third case is similar; and the fourth case is as in Section 10.3. 1. 

Notice that the correctness of the second case hinges on the 
very mathematical property that it implements, i.e., that zero is a 
left identity for addition. Any such property can be encoded into 
the implementation and then verified in this way. The discipline of 
type class morphisms ensure that all optimizations are correct. 

11. Fusing folds 

Folds are common in functional programming, to express a cumu- 
lative iteration over a list (or other data structure), reducing to a 
single value. There are two flavors, left- and right-associating: 

foldl (©) a [bi, b 2 , ...,&„] = (...((a 0 6i) 0 b 2 ) 0 ...) 0 b„ 

foldr (0) a [6i, b 2 ,...,b„] = bi 0 (b 2 0 ...(&„ 0 a)...) 

Written recursively, 

foldl :: (a — > b — > a) — > a — > [6] — > a 

foldl (0) a [] = a 

foldl (0) a \b : bs) = foldl (0) (a 0 b) bs 

foldr :: (b — > a — > a) — > a — > [6] — > a 

/oWr _ a [] = a 

/oMr (0) a (6 : bs) = b 0 (foldr (0) a &s) 

There is also a strict variant of foldl, which eliminates a common 
form of space leak. 

If a fold is the only use of a list, then lazy evaluation and garbage 
collection conspire to produce efficient use of memory. Laziness 
delays computation of list cells until just before they're combined 
into the fold result (using (0)), after which they become inacces- 
sible and can be collected. This pattern allows list generation and 
folding to run in constant space, regardless of the length of inter- 
mediate list. (Compile-time fusion can make this process even more 
efficient.) Non-strict and right folds can leak due to thunks. 

On the other hand, if a single list is folded over twice, then 
the entire list will be kept in memory to make the second fold 
possible. Borrowing a common example, consider the following 
naive implementation of the average of the values in a list: 

naiveMean :: Fractional a => [a] — > a 
naiveMean xs = sum xs / fromlntegral (length xs) 

Each of sum and length can be defined as a (strict) left-fold: 

sum — foldl (+) 0 

length — foldl (\a _ — > a + 1) 0 

Max Rabkin (2008) gave an elegant way to fuse these two foldl 
passes into one, reducing the space usage from linear to constant. 
We'll see that Max's optimization and its correctness flow from a 
semantic model and its type class morphisms. 

As a first step, let's look at a simpler setting: turning a pair of 
non-strict left foldings into a single one. Given combiners (©) and 



(0) and initial values e and e', come up with (□) and e" such that 
one fold replaces a pair of them: 

(foldl (0) e bs, foldl (0) e' bs) = foldl (□) e" bs 

11.1 Folds as data 

We want to combine the two left folds before supplying the list 
argument, rather than after. To do so, make a data type for the partial 
application that does not include the final (list) argument. 

data FoldL b a — F (a ^ b ^ a) a 

The FoldL is not just a representation; it has meaning, which is 
partially applied folding: 

[■] :: FoldL b a -> ([b] -> a) 
{FoldL (0) e] = foldl (0) e 

With this representation and meaning, we can rephrase our goal: 
given two left folds / and /', find another fold /" such that 

([/] bs, I/'] bs) = I/"] bs 

In other words, 

[/] m [/'] = [/"] 

where (Sfc) is a common operation on functions (more generally, 
on arrows (Hughes 2000)): 

(ffiz) :: (x -> a) -> (x -> b) -> (x -> {a, b)) 
f Ml g = \x -» (/ x,g x) 

Of course, we want a systematic way to construct /", so we're 
really looking for a combining operation 

combL :: FoldL c a — > FoldL c b — > FoldL c (a, b) 

such that for for all / and /' 

]f]Sk\f'] = \f' combL'f'j 

This last form is tantalizingly close to a type class morphism. 
What's missing is a shared type class method. 

11.2 Generalized zipping 

Consider the types of the following three functions: 

zip :: Stream a — » Stream b — » Stream (a, b) 
(®k) ::(c-+ a)^(c^ b) (c (a, b)) 

combL :: FoldL c a — > FoldL c b — > FoldL c (a, b) 

These functions and more can be subsumed by a more general no- 
tion of zipping. Streams, functions, and folds also have in common 
that they provide a "unit", which will turn out to be useful later. 
These two common features are embodied in a type class: 

class Zip f where 

unit f () 

(*) "fa->fb->f(a,b) 

Streams and functions zip. Do folds? 

The Zip class corresponds to Monoidal class (McBride and Pa- 
terson 2008, Section 7), except that Monoidal requires a Functor, 
which is not the case with FoldL. 

Generalized (*) gives us our target TCM. Zipping a left fold 
means finding a semantic Zip morphism, i.e., 

[ww<] ee unit 

U]*\f'] = \f*f'\ 

The following definition suffices: 6 

6 With this definition, the (★) morphism property fails when / = _L or 
/' = _L. To fix this problem, use lazy patterns in the definition. My thanks 
to Ryan Ingram for pointing out this bug. 
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instance Zip (FoldL 6) where 
unit = F const () 
F (&) e*F(0) e' = F(H) (e, e') 
where 

(a, a') □ 6 = (a © 6, a' 0 6) 

To prove that [•] is Zip morphism, first substitute the definitions 
of (★) for functions and for folds and the definition of [•] into the 
morphism property. We'll want some structure to work with, so let 
F (0) e = / and F (0) e' = /'. First, the unit morphism 
property, for empty lists: 

{unit} [} 
= { [■] definition } 

foldl const () [] 
= { foldl definition } 

0 

= { unit for functions } 

unit [] 

Then for empty lists: 

[unit} (b : bs) 
= { [•] definition } 

foldl const () (6 : bs) 
= { foldl definition } 

foldl const (const () 6) bs 
= { const definition } 

foldl const () bs 
= { const definition } 

foldl const () bs 
= { [•] definition } 

[iimi] 6s 
= { induction } 

unit bs 

After simplifying, the second morphism law becomes 

foldl (□) (e, e') bs = (foldl (©) e bs, foldl (0) e' bs) 
where 

(a, a') □ b = (a 0 6, a' 0 6) 

Prove this form inductively in the list 6s, using the definition of 
foldl. First, empty lists. 

foldl (□) (e, e') [] where (□) = ... 
ee { foldl definition } 

(e,e') 
ee {foldl def, twice } 

(/oidi (0)e[],/bWJ (0)e'[]) 
Next, non-empty lists. 

foldl (□) (e, e') (6 : bs) where (□) = ... 
ee { foldl definition } 

foldl (□) ((e, e') □ 6) 6s where (□) = ... 
ee { (□) definition } 

foldl (□) (e 0 b, e' 0 b) bs where (□) = ... 
ee { induction hypothesis } 

(foldl (0) (e 0 b) bs, foldl (0) (e' 0 6) bs) 
ee {foldl def, twice } 

(/oZa7 (0) e (6 : bs), foldl (0) e' (6 : 6s)) 

11.3 Variations 

Right folds work similarly. Strict folds are trickier but also impor- 
tant, to prevent space leaks. See (Rabkin 2008) and (Elliott 2008). 

Can we add more instances for FoldL, with corresponding se- 
mantic morphisms? Let's try Functor: 



instance Functor (FoldL b) where 
frnap h (FoldL (0) e) ee FoldL (0) e' where ... ?? 

The functor morphism law says that 

Ifmap h (FoldL (0) e)] ee frnap h [FoldL (0) e] 

Substituting our partial frnap definition on the left and (o) for frnap 
on the right, as well as the definition of [■], the property becomes 

foldl (0) e' ee ho foldl (0) e where ... 

At this point, I'm stuck, as I don't see a way to get foldl to apply 
h just at the end of a fold. Max solved this problem by adding a 
post-fold function to the FoldL type (Rabkin 2008). Generalizing 
from his solution, we can extend any zippable type constructor to 
have Functor instance, and many to have Applicative, as we'll 
see next. 

12. Enhanced zipping 

To get from Zip to Functor and Applicative, add a final phase 

data WithCont z c = Va. WC (z a) (a -» c) 

The "Va" keeps the intermediate value's type from complicating 
the type of a WithCont. 

Given a semantic function ((•)) :: z a — > u a, for a functor u, 
the meaning of WithCont is 

[■] :: WithCont z c — > u c 
\WC zk\ = frnap k ((z)) 

For instance, adding Max's post-fold step just requires wrapping 
FoldL with WithCont: 

type FoldLC b = WithCont (FoldL 6) 

Since the meaning of a FoldL is a function, the frnap in [•] is 
function composition, exactly as we want for applying a post-fold 
step. It's now easy to define instances. 

12.1 Functor and Zip 

The Functor instance accumulates final steps: 

instance Functor (WithCont z) where 
frnap g (WC z k) = WC z (go k) 

Its morphism property: 

Ifmap g (WC z k)} 
ee { frnap on WithCont } 

\WC z (go k)J 
ee { [•] definition } 

frnap (g o k) ({z}} 
ee { Second Functor law } 

frnap g (frnap k ((z))) 
ee { [•] definition } 

frnap g \ WC z k} 

[To do: Also consider _LJ The Zip instance delegates to the inner 
Zip, and pairs up final transformations. 

instance Zip z => Zip ( WithCont z) where 
unit = WC _L (const ()) 

WC fa ka ★ WC fb kb = WC (fa*fb) (ka x kb) 
First unit: 
funitj 

ee { unit on WithCont } 

\WC _L (const ())] 
ee { [•] definition } 

frnap (const ()) ((_!_)) 
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If we had the following property, we would be done: 

fmap (const ()) m = unit — required 

This property is satisfied for some functors (including ((—»•) a)) but 
not others (e.g., []), so the unit morphism property holds only for 
some functors z (with semantic model u), including the meaning 
of FoldL. 

Next, the (*) morphism property: 

\WC fa ka-k WC fb kbj 
= { (*) on WithCont } 

\WC (fa-kfb) (ka x kb)J 
= { [•] definition } 

fmap (ka x kb) ((fa * fb}} 
= {((■}} is a Zip morphism } 

fmap (ka x kb) (((fa}} * ((fb}}) 
= { naturality of (*) } 

fmap ka ((fa}} * fmap kb ((fb}} 
= { [•] definition, twice } 

[WC fa kaj-k{WC fb kbj 

12.2 Applicative 

As pointed out in (McBride and Paterson 2008, Section 7), the 
Applicative class has an equivalent but more symmetric variation, 
which is the (strong) lax monoidal functor, which has the interface 
of Zip, in addition to Functor. Using the standard Applicative 
instance for lax monoidal functors: 

instance (Functor z, Zip z) => 

Applicative ( WithCont z) where 
pure a = fmap (const a) unit 
wf © wx — fmap app (wf * wx) 

app (/, x)=f x 

the morphism proof runs into a bit of trouble for pure: 

{pure a} = {fmap (const a) unit] 
= fmap (const a) {unit} 
= fmap (const a) unit 
= pure a — note: only sometimes 

Again, the required property is satisfied for some functors, includ- 
ing the meaning of FoldL. Continuing, 

Ifs © xsj = If map app (fs * xs)} 
= fmap app Ifs * xsj 
= fmap app ([/s] * (xsj) 
= ]fs] © Ixs] 

Thanks to this morphism, we have a zipping law for folds: 

UftA 2 h (k o foldl (0) e) (k' o foldl (o) e') 

{UftA 2 h(WC k (FoldL (0) e)) (WC k' (FoldL (Q) e'))J 

and similarly for HftA 3 , etc. The proof is a direct application of the 
semantics and the morphism properties. This transformation could 
be automated with rewrite rules (Peyton Jones et al. 2001). 
Returning to the example of combining two folds into one. 

naiveMean :: Fractional a => [a] — > a 
naiveMean xs = sum xs / fromlntegral (length xs) 

In point-free form, 

naiveMean = UftA 2 (/) sum (fromlntegral o length) 
So an equivalent optimized definition is 



zippedMean — 

{HftA 2 (/) (WC id (FoldL (+) 0)) 

( WC fromlntegral (FoldL (Xa _ -> a + 1) 0))] 

13. Some more examples 

13.1 Functional reactive programming 

My first exposure to type class morphisms was in giving a denota- 
tional semantics to functional reactive programming (FRP) struc- 
tured into type classes (Elliott 2009b). "Classic FRP" is based on a 
model of behaviors as functions of time (Elliott and Hudak 1997). 

[•] :: Behavior a — > (Time — » a) 

For instance, a 3D animation has type Behavior Geometry, and 
its meaning is Time — » Geometry. 

Much of FRP can be re-packaged via type classes. In most 
cases, the semantics is specified simply and fully by saying that 
the semantic function is a TCM. For events, where the TCM princ- 
ple is not applied successfully, the semantics is problematic. (For 
instance, the monad associativity law can fail.) 

13.2 Functional image synthesis 

Pan is a system for image synthesis and manipulation with a purely 
functional model and a high-performance implementation (Elliott 
2003; Elliott et al. 2003). The semantic model for images in Pan is 
simply functions of continuous infinite 2D space: 

[•] :: Image a — > (K 2 — > a) 

With this semantic model, the Image type has instances for 
Functor and Applicative, which form the basis of all point-wise 
operations, including cropping and blending. With the TCM prin- 
ciple clearly in mind, the Image interface can be made more con- 
venient, regular and powerful, via instances of Monoid, Monad 
and Comonad, as well all of the number classes. 

The implementation uses a self-optimizing syntactic represen- 
tation, packaged as numeric class instances, akin to that in Sec- 
tion 10.3.5. The semantic function, therefore, is a morphism over 
all of the classes mentioned. 

13.3 Automatic differentiation 

Automatic differentiation (AD) is a precise and efficient method for 
computing derivatives. It has a simple specification in terms of type 
class morphisms, from which an elegant, correct implementation 
can be derived. The specification and implementations can then 
be generalized considerably to computing higher-order derivatives 
(infinitely many of them, lazily) and derivatives of functions over 
arbitrary vector spaces (Elliott 2009a). 

14. Conclusions — advice on software design 

With the examples in this paper, I am conveying some advice to 
my fellow programmers: when designing software, in addition to 
innovating in your implementations, relate them to precise and 
familiar semantic models. Implementing those models faithfully 
guarantees that your library's users will get simple semantics and 
expected properties, in addition to whatever performance benefits 
you provide. 

By defining a type's denotation clearly, library designers can 
ensure there are no abstraction leaks. When the semantic function 
maps two program values to the same mathematical value, the de- 
signer must ensure that those program values be indistinguishable, 
in order to prevent semantic abstraction leaks. The discipline of 
denotational semantics, applied to data types, ensures that this con- 
dition is satisfied, simply because each operation's meaning is de- 
fined purely in terms of the meaning of its arguments. 
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Type classes introduce a new source of potential abstraction 
leaks, by allowing a single name to be used at different types. 
Although a type class dictates a set of necessary properties, it also 
leaves room for variation in semantics and implementation. For 
each program type, the library designer must take care that each 
interface (type class) implementation behaves consistently with the 
type's model, i.e., 

The instance's meaning follows the meaning's instance. 

which is to say that the semantic function is to be a "type class mor- 
phism" (TCM) for each type class implemented. When a library not 
only type-checks, but also morphism-checks, it is free of abstraction 
leak, and so the library's users can safely treat a program value as 
being its meaning. As a bonus, type class laws are guaranteed to 
hold, because they carry over directly from the semantic model. As 
much as good models tend to be widely reusable, effort invested in 
studying them is leveraged. 

Finally, I see denotational, TCM-based design as in the spirit of 
John Reynolds's use of category theory for language design. 

Our intention is not to use any deep theorems of category 
theory, but merely to employ the basic concepts of this field 
as organizing principles. This might appear as a desire to be 
concise at the expense of being esoteric. But in designing a 
programming language, the central problem is to organize a 
variety of concepts in a way which exhibits uniformity and 
generality. Substantial leverage can be gained in attacking 
this problem if these concepts are defined concisely within 
a framework which has already proven its ability to impose 
uniformity and generality upon a wide variety of mathemat- 
ics (Reynolds 1980). 
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